Realizing a large-scale system (such as an airplane, space shuttle, submarine, helicopter, power plant, aircraft carrier, or the like) constitutes a complex undertaking. Without exception, such large-scale systems are comprised of a working conglomeration of smaller-scale systems, which themselves are comprised of even smaller-scale systems, and so forth. Notwithstanding the necessity of building, retaining, and imparting an overall vision of a large-scale system, it is nevertheless imperative that such a system be defined in detail to the level of the individual constituent components that together bring the system to physical being.
The overall design of a large-scale system is usually represented and realized by thousands of design artifacts (including virtual and hardcopy documents such as schematic diagrams, data tables, instructional text, exploded graphic views, and so forth). Together these design artifacts represent the knowledge the enterprise has regarding the design and manufacture of the large-scale system itself Also typically, however, considerable overlap often exists between these design artifacts; that is, the contents of each artifact are usually not mutually exclusive to the contents of all other artifacts. For example, a given component or role such as a circuit breaker may appear in multiple artifacts (some dealing with the electric connections, some dealing with the part number and source, some dealing with the physical mounting of the object, and so forth). The more integrated the large-scale system, the more likely an overlap exists between its artifacts. The existence of such multiple views can and will often lead to contradictions between the artifacts. For example, a parts listing artifact may identify a given circuit breaker as being a particular device from a particular supplier while a diagram artifact identifying the location of mounting holes for the circuit breaker may reflect a different part altogether. Ultimately, agreement must be achieved between such artifacts. Unfortunately, at best, the cost of resolving discovered contradictions is surprisingly high (for example, $25,000 in total overall costs and expenses can easily be consumed to resolve a single contradiction in a large-scale system such as a commercial airliner). And, at worst, the contradiction goes undiscovered until a corresponding problem brings the circumstance to light.
The above problem results at least in part due to scattering of the essential knowledge represented in these various design artifacts through the enterprise (in multiple information systems) and across the large-scale design activities. So-called single source design constructs have been theoretically proposed in the prior art as a conceptual way to avoid at least some of these issues. Pursuant to such a notion, all knowledge regarding a given product is contained in a single product definition regardless of how many views may be available to access such knowledge. Unfortunately, such constructs have remained more theoretical than real; one key obstacle has been identifying a way to represent the knowledge of the enterprise in the single source system. As one facet of the problem, different views (including combinations and/or formatting elections) of the knowledge are required to suit various participants and activities during the design and subsequent manufacture of the large-scale system. As another side of the problem, thousands of variations are possible with virtually any given design. No one has presented an effective way to accommodate such multiple configurations within a single source context.
Therefore, notwithstanding a long-understood problem that contributes greatly and frequently to design and manufacture delay, quality issues, and costly expenditures, industry continues more or less to use traditional knowledge management tools and their corresponding views and product artifacts to bring large-scale systems from concept to reality.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are typically not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. Those skilled in the art will also recognize that much of the information is presented using the Unified Modeling Language. The Unified Modeling Language is a known prior art language standard (as developed and specified by the Object Management Group) for specifying, visualizing, constructing, and documenting the artifacts of systems (including software systems, business models, and hardware systems).